home *** CD-ROM | disk | FTP | other *** search
_✓1. _✓S_✓e_✓t_✓t_✓i_✓n_✓g _✓B_✓u_✓f_✓s_✓i_✓z_✓e, _✓P_✓a_✓c_✓l_✓e_✓n, _✓M_✓a_✓x_✓f_✓r_✓a_✓m_✓e, _✓M_✓T_✓U, _✓M_✓S_✓S _✓a_✓n_✓d _✓W_✓i_✓n_✓d_✓o_✓w Many NET users are confused by these parameters and do not know how to set them properly. This section will first review these parameters and then discuss how to choose values for them. Special emphasis is given to avoiding interoperability problems that may appear when communicating with non-NET implementations of AX.25. _✓1._✓1. _✓H_✓a_✓r_✓d_✓w_✓a_✓r_✓e _✓P_✓a_✓r_✓a_✓m_✓e_✓t_✓e_✓r_✓s _✓1._✓1._✓1. _✓B_✓u_✓f_✓s_✓i_✓z_✓e This parameter is required by most of NET's built-in HDLC drivers (e.g., those for the DRSI PCPA and the Paccomm PC- 100). It specifies the size of the buffer to be allocated for each receiver port. HDLC frames larger than this value cannot be received. There is no default b✓b✓b✓bu✓u✓u✓uf✓f✓f✓fs✓s✓s✓si✓i✓i✓iz✓z✓z✓ze✓e✓e✓e; it must be specified in the a✓a✓a✓at✓t✓t✓tt✓t✓t✓ta✓a✓a✓ac✓c✓c✓ch✓h✓h✓h command for the interface. _✓1._✓2. _✓A_✓X_✓2_✓5 _✓P_✓a_✓r_✓a_✓m_✓e_✓t_✓e_✓r_✓s _✓1._✓2._✓1. _✓P_✓a_✓c_✓l_✓e_✓n Paclen limits the size of the data field in an AX.25 I- frame. This value does _✓n_✓o_✓t include the AX.25 protocol header (source, destination and digipeater addresses). Since unconnected-mode (datagram) AX.25 uses UI frames, this parameter has no effect in unconnected mode. The default value of p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n in NET is 256 bytes. _✓1._✓2._✓2. _✓M_✓a_✓x_✓f_✓r_✓a_✓m_✓e This parameter controls the number of I-frames that NET may send on an AX.25 connection before it must stop and wait for an acknowledgement. Since the AX.25/LAPB sequence number field is 3 bits wide, this number cannot be larger than 7. Since unconnected-mode (datagram) AX.25 uses UI frames that do not have sequence numbers, this parameter does _✓n_✓o_✓t apply to unconnected mode. The default value of m✓m✓m✓ma✓a✓a✓ax✓x✓x✓xf✓f✓f✓fr✓r✓r✓ra✓a✓a✓am✓m✓m✓me✓e✓e✓e in NET is 1 frame. _✓1._✓3. _✓I_✓P _✓a_✓n_✓d _✓T_✓C_✓P _✓P_✓a_✓r_✓a_✓m_✓e_✓t_✓e_✓r_✓s June 3, 1990 - 2 - _✓1._✓3._✓1. _✓M_✓T_✓U The MTU (Maximum Transmission Unit) is an interface parame- ter that limits the size of the largest IP datagram that it may handle. IP datagrams routed to an interface that are larger than its MTU are each split into two or more _✓f_✓r_✓a_✓g_✓- _✓m_✓e_✓n_✓t_✓s. Each fragment has its own IP header and is handled by the network as if it were a distinct IP datagram, but when it arrives at the destination it is held by the IP layer until all of the other fragments belonging to the ori- ginal datagram have arrived. Then they are reassembled back into the complete, original IP datagram. The minimum accept- able interface MTU is 28 bytes: 20 bytes for the IP (frag- ment) header, plus 8 bytes of data. There is no default MTU in NET; it must be explicitly speci- fied for each interface as part of the a✓a✓a✓at✓t✓t✓tt✓t✓t✓ta✓a✓a✓ac✓c✓c✓ch✓h✓h✓h command. _✓1._✓3._✓2. _✓M_✓S_✓S MSS (Maximum Segment Size) is a TCP-level parameter that limits the amount of data that the _✓r_✓e_✓m_✓o_✓t_✓e TCP will send in a single TCP packet. MSS values are exchanged in the SYN (con- nection request) packets that open a TCP connection. In the NET implementation of TCP, the MSS actually used by TCP is further reduced in order to avoid fragmentation at the local IP interface. That is, the local TCP asks IP for the MTU of the interface that will be used to reach the destination. It then subtracts 40 from the MTU value to allow for the over- head of the TCP and IP headers. If the result is less than the MSS received from the remote TCP, it is used instead. The default value of M✓M✓M✓MS✓S✓S✓SS✓S✓S✓S in NET is 512 bytes. _✓1._✓3._✓3. _✓W_✓i_✓n_✓d_✓o_✓w This is a TCP-level parameter that controls how much data the local TCP will allow the remote TCP to send before it must stop and wait for an acknowledgement. The actual window value used by TCP when deciding how much more data to send is referred to as the _✓e_✓f_✓f_✓e_✓c_✓t_✓i_✓v_✓e _✓w_✓i_✓n_✓d_✓o_✓w. This is the smaller of two values: the window advertised by the remote TCP minus the unacknowledged data in flight, and the _✓c_✓o_✓n_✓g_✓e_✓s_✓t_✓i_✓o_✓n _✓w_✓i_✓n_✓- _✓d_✓o_✓w, an automatically computed time-varying estimate of how much data the network can handle. The default value of W✓W✓W✓Wi✓i✓i✓in✓n✓n✓nd✓d✓d✓do✓o✓o✓ow✓w✓w✓w in NET is 2048 bytes. _✓1._✓4. _✓D_✓i_✓s_✓c_✓u_✓s_✓s_✓i_✓o_✓n June 3, 1990 - 3 - _✓1._✓4._✓1. _✓I_✓P _✓F_✓r_✓a_✓g_✓m_✓e_✓n_✓t_✓a_✓t_✓i_✓o_✓n _✓v_✓s _✓A_✓X._✓2_✓5 _✓S_✓e_✓g_✓m_✓e_✓n_✓t_✓a_✓t_✓i_✓o_✓n IP-level fragmentation often makes it possible to intercon- nect two dissimilar networks, but it is best avoided when- ever possible. One reason is that when a single IP fragment is lost, all other fragments belonging to the same datagram are effectively also lost and the entire datagram must be retransmitted by the source. Even without loss, fragments require the allocation of temporary buffer memory at the destination, and it is never easy to decide how long to wait for missing fragments before giving up and discarding those that have already arrived. A reassembly timer controls this process. In NET it is (re)initialized with the i✓i✓i✓ip✓p✓p✓p r✓r✓r✓rt✓t✓t✓ti✓i✓i✓im✓m✓m✓me✓e✓e✓er✓r✓r✓r parameter (default 30 seconds) whenever progress is made in reassembling a datagram (i.e., a new fragment is received). It is not necessary that all of the fragments belonging to a datagram arrive within a single timeout interval, only that the interval between fragments be less than the timeout. Most subnetworks that carry IP have MTUs of 576 bytes or more, so interconnecting them with subnetworks having smaller values can result in considerable fragmentation. For this reason, IP implementors working with links or subnets having unusually small packet size limits are encouraged to use _✓t_✓r_✓a_✓n_✓s_✓p_✓a_✓r_✓e_✓n_✓t _✓f_✓r_✓a_✓g_✓m_✓e_✓n_✓t_✓a_✓t_✓i_✓o_✓n, that is, to devise schemes to break up large IP datagrams into a sequence of link or sub- net frames that are immediately reassembled on the other end of the link or subnet into the original, whole IP datagram without the use of IP-level fragmentation. Such a scheme is provided in AX.25 Version 2.1. It can break a large IP or NET/ROM datagram into a series of p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n-sized AX.25 seg- ments (not to be confused with TCP segments), one per AX.25 I-frame, for transmission and reassemble them into a single datagram at the other end of the link before handing it up to the IP or NET/ROM module. Unfortunately, the segmenta- tion procedure is a new feature in AX.25 and is not yet widely implemented; in fact, NET is so far the only known implementation. This creates some interoperability problems between NET and non-NET nodes, in particular, standard NET/ROM nodes being used to carry IP datagrams. This problem is discussed further in the section on setting the MTU. _✓1._✓4._✓2. _✓S_✓e_✓t_✓t_✓i_✓n_✓g _✓p_✓a_✓c_✓l_✓e_✓n _✓a_✓n_✓d _✓b_✓u_✓f_✓s_✓i_✓z_✓e The more data you put into an AX.25 I frame, the smaller the AX.25 headers are in relation to the total frame size. In other words, by increasing p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n, you lower the AX.25 pro- tocol overhead. Also, large data packets reduce the overhead of keying up a transmitter, and this can be an important factor with higher speed modems. On the other hand, large frames make bigger targets for noise and interference. Each link has an optimum value of p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n that is best discovered by experiment. June 3, 1990 - 4 - Another thing to remember when setting p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n is that the AX.25 version 2.0 specification limits it to 256 bytes. Although NET can handle much larger values, some other AX.25 implementations (including digipeaters) cannot and this may cause interoperability problems. Even NET may have trouble with certain KISS TNCs because of fixed-size buffers. The original KISS TNC code for the TNC-2 by K3MC can handle frames limited in size only by the RAM in the TNC, but some other KISS TNCs cannot. NET's built-in HDLC drivers (SCC, PC-100, DRSI, etc) allo- cate receive buffers according to the maximum expected frame size, so it is important that these devices be configured with the correct b✓b✓b✓bu✓u✓u✓uf✓f✓f✓fs✓s✓s✓si✓i✓i✓iz✓z✓z✓ze✓e✓e✓e. To do this, you must know the size of the largest possible frame that can be received. The p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n parameter controls only the size of the data field in an I-frame and not the total size of the frame as it appears on the air. The AX.25 spec allows up to 8 digipeaters, so the largest possible frame is (p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n + 72) bytes. So you should make b✓b✓b✓bu✓u✓u✓uf✓f✓f✓fs✓s✓s✓si✓i✓i✓iz✓z✓z✓ze✓e✓e✓e at least this large. Another important consideration is that the more recent ver- sions of NOS improve interrupt response by maintaining a special pool of buffers for use by the receive routines. These buffers are currently fixed in size to 2048 bytes and this can be changed only by editing config.h and recompiling NOS. This limits b✓b✓b✓bu✓u✓u✓uf✓f✓f✓fs✓s✓s✓si✓i✓i✓iz✓z✓z✓ze✓e✓e✓e; in fact, attempting to set a larger value may cause the driver not to work at all. This situation can be detected by running the m✓m✓m✓me✓e✓e✓em✓m✓m✓mo✓o✓o✓or✓r✓r✓ry✓y✓y✓y s✓s✓s✓st✓t✓t✓ta✓a✓a✓at✓t✓t✓tu✓u✓u✓us✓s✓s✓s com- mand and looking for a non-zero count of I✓I✓I✓Ib✓b✓b✓bu✓u✓u✓uf✓f✓f✓ff✓f✓f✓fa✓a✓a✓ai✓i✓i✓il✓l✓l✓l events, although these events can also occur occasionally during normal operation. One of the drawbacks of AX.25 that there is no way for one station to tell another how large a packet it is willing to accept. This requires the stations sharing a channel to agree beforehand on a maximum packet size. TCP is dif- ferent, as we shall see. _✓1._✓4._✓3. _✓S_✓e_✓t_✓t_✓i_✓n_✓g _✓M_✓a_✓x_✓f_✓r_✓a_✓m_✓e For best performance on a half-duplex radio channel, m✓m✓m✓ma✓a✓a✓ax✓x✓x✓x-✓-✓-✓- f✓f✓f✓fr✓r✓r✓ra✓a✓a✓am✓m✓m✓me✓e✓e✓e should always be set to 1. The reasons are explained in the paper _✓L_✓i_✓n_✓k _✓L_✓e_✓v_✓e_✓l _✓P_✓r_✓o_✓t_✓o_✓c_✓o_✓l_✓s _✓R_✓e_✓v_✓i_✓s_✓i_✓t_✓e_✓d by Brian Lloyd and Phil Karn, which appeared in the proceedings of the ARRL 5th Computer Networking Conference in 1986. _✓1._✓4._✓4. _✓S_✓e_✓t_✓t_✓i_✓n_✓g _✓M_✓T_✓U TCP/IP header overhead considerations similar to those of the AX.25 layer when setting p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n apply when choosing an MTU. However, certain subnetwork types supported by NET have well-established MTUs, and these should always be used unless you know what you're doing: 1500 bytes for Ethernet, June 3, 1990 - 5 - and 253 bytes for ARCNET. Other subnet types, including SLIP and AX.25, are not as well standardized. SLIP has no offi- cial MTU, but the most common implementation (for BSD UNIX) uses an MTU of 1006 bytes. Although NET has no hard wired limit on the size of a received SLIP frame, this is not true for other systems. Interoperability problems may therefore result if larger MTUs are used in NET. Choosing an MTU for an AX.25 interface is more complex. When the interface operates in datagram (UI-frame) mode, the p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n parameter does not apply. The MTU effectively becomes the p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n of the link. However, as mentioned earlier, large packets sent on AX.25 _✓c_✓o_✓n_✓n_✓e_✓c_✓t_✓i_✓o_✓n_✓s are automatically segmented into I-frames no larger than p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n bytes. Unfor- tunately, as also mentioned earlier, NET is so far the only known implementation of the new AX.25 segmentation pro- cedure. This is fine as long as all of the NET/ROM nodes along a path are running NET, but since the main reason NET supports NET/ROM is to allow use of existing NET/ROM net- works, this is unlikely. So it is usually important to avoid AX.25 segmentation when running IP over NET/ROM. The way to do this is to make sure that packets larger than p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n are never handed to AX.25. A NET/ROM transport header is 5 bytes long and a NET/ROM network header takes 15 bytes, so 20 bytes must be added to the size of an IP datagram when figuring the size of the AX.25 I-frame data field. If p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n is 256, this leaves 236 bytes for the IP datagram. This is the default MTU of the n✓n✓n✓ne✓e✓e✓et✓t✓t✓tr✓r✓r✓ro✓o✓o✓om✓m✓m✓m pseudo-interface, so as long as p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n is at least 256 bytes, AX.25 segmentation can't happen. But if smaller values of p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n are used, the n✓n✓n✓ne✓e✓e✓et✓t✓t✓tr✓r✓r✓ro✓o✓o✓om✓m✓m✓m MTU must also be reduced with the i✓i✓i✓if✓f✓f✓fc✓c✓c✓co✓o✓o✓on✓n✓n✓nf✓f✓f✓fi✓i✓i✓ig✓g✓g✓g command. On the other hand, if you're running IP directly on top of AX.25, chances are all of the nodes are running NET and sup- port AX.25 segmentation. In this case there is no reason not to use a larger MTU and let AX.25 segmentation do its thing. If you choose an MTU on the order of 1000-1500 bytes, you can largely avoid IP-level fragmentation and reduce TCP/IP-level header overhead on file transfers to a very low level. And you are still free to pick whatever p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n value is appropriate for the link. _✓1._✓4._✓5. _✓S_✓e_✓t_✓t_✓i_✓n_✓g _✓M_✓S_✓S The setting of this TCP-level parameter is somewhat less critical than the IP and AX.25 level parameters already dis- cussed, mainly because it is automatically lowered according to the MTU of the local interface when a connection is created. Although this is, strictly speaking, a protocol layering violation (TCP is not supposed to have any knowledge of the workings of lower layers) this technique does work well in practice. However, it can be fooled; for June 3, 1990 - 6 - example, if a routing change occurs after the connection has been opened and the new local interface has a smaller MTU than the previous one, IP fragmentation may occur in the local system. The only drawback to setting a large MSS is that it might cause avoidable fragmentation at some other point within the network path if it includes a "bottleneck" subnet with an MTU smaller than that of the local interface. (Unfor- tunately, there is presently no way to know when this is the case. There is ongoing work within the Internet Engineering Task Force on a "MTU Discovery" procedure to determine the largest datagram that may be sent over a given path without fragmentation, but it is not yet complete.) Also, since the MSS you specify is sent to the remote system, and not all other TCPs do the MSS-lowering procedure yet, this might cause the remote system to generate IP fragments unneces- sarily. On the other hand, a too-small MSS can result in a consider- able performance loss, especially when operating over fast LANs and networks that can handle larger packets. So the best value for MSS is probably 40 less than the largest MTU on your system, with the 40-byte margin allowing for the TCP and IP headers. For example, if you have a SLIP interface with a 1006 byte MTU and an Ethernet interface with a 1500 byte MTU, set MSS to 1460 bytes. This allows you to receive maximum-sized Ethernet packets, assuming the path to your system does not have any bottleneck subnets with smaller MTUs. _✓1._✓4._✓6. _✓S_✓e_✓t_✓t_✓i_✓n_✓g _✓W_✓i_✓n_✓d_✓o_✓w A sliding window protocol like TCP cannot transfer more than one window's worth of data per round trip time interval. So this TCP-level parameter controls the ability of the remote TCP to keep a long "pipe" full. That is, when operating over a path with many hops, offering a large TCP window will help keep all those hops busy when you're receiving data. On the other hand, offering too large a window can congest the net- work if it cannot buffer all that data. Fortunately, new algorithms for dynamic controlling the effective TCP flow control window have been developed over the past few years and are now widely deployed. NET includes them, and you can watch them in action with the t✓t✓t✓tc✓c✓c✓cp✓p✓p✓p s✓s✓s✓st✓t✓t✓ta✓a✓a✓at✓t✓t✓tu✓u✓u✓us✓s✓s✓s <✓<✓<✓<t✓t✓t✓tc✓c✓c✓cb✓b✓b✓b>✓>✓>✓> or s✓s✓s✓so✓o✓o✓oc✓c✓c✓ck✓k✓k✓ke✓e✓e✓et✓t✓t✓t <✓<✓<✓<s✓s✓s✓so✓o✓o✓oc✓c✓c✓ck✓k✓k✓kn✓n✓n✓no✓o✓o✓o>✓>✓>✓> commands. Look at the c✓c✓c✓cw✓w✓w✓wi✓i✓i✓in✓n✓n✓nd✓d✓d✓d (congestion window) value. In most cases it is safe to set the TCP window to a small integer multiple of the MSS, e.g., 4x, or larger if neces- sary to fully utilize a high bandwidth*delay product path. One thing to keep in mind, however, is that advertising a certain TCP window value declares that the system has that much buffer space available for incoming data. NET does not June 3, 1990 - 7 - actually preallocate this space; it keeps it in a common pool and may well "overbook" it, exploiting the fact that many TCP connections are idle for long periods and gambling that most applications will read incoming data from an active connection as soon as it arrives, thereby quickly freeing the buffer memory. However, it is possible to run NET out of memory if excessive TCP window sizes are adver- tised and either the applications go to sleep indefinitely (e.g., suspended TELNET sessions) or a lot of out-of- sequence data arrives. It is wise to keep an eye on the amount of available memory and to decrease the TCP window size (or limit the number of simultaneous connections) if it gets too low. Depending on the channel access method and link level proto- col, the use of a window setting that exceeds the MSS may cause an increase in channel collisions. In particular, col- lisions between data packets and returning acknowledgements during a bulk file transfer may become common. Although this is, strictly speaking, not TCP's fault, it is possible to work around the problem at the TCP level by decreasing the window so that the protocol operates in stop-and-wait mode. This is done by making the window value equal to the MSS. _✓1._✓5. _✓S_✓u_✓m_✓m_✓a_✓r_✓y In general, the default values provided by NET for each of these parameters will work correctly and give reasonable performance. Only in special circumstances such as operation over a very poor link or experimentation with high speed modems should it be necessary to change them. June 3, 1990 
